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Sir, 

I, Alexander Medvinsky, hereby declare as follows: 

1 I am the named and true inventor in the above referenced patent application and 
that I am the sole inventor of the subject matter disclosed and claimed in the above 
referenced patent application 


3 2006 \2 :05PM 


MOTOROLA 


No 1363 P 3 


U.S. Serial No.: 09/765,108 


2. I submitted a description of my invention, now claimed in claims 1-7 and 10-23 
of the above application, to the law department of General Instrument Corporation in an 
"Invention Record Form," I signed the Invention Record Form on September 12, 2000 
and the signatures on the Invention Record Form are my own. A redacted copy of the 
Invention Record Form is provided with this declaration as Attachment A which includes 
a copy of a paper describing the invention. 

3 .. I conceived the invention recited in claims 1 -7 and 1 0-23 of the above application 
prior to December 1 9, 2000. See, Attachment A, Invention Record Form 

4 Upon information and belief, the stamp bearing the date of September 1 9, 2000 
on the front of the Invention Record Form was placed thereon by the law department of 
General Instrument Corporation and indicates the date of receipt of the Invention Record 
Form, 

5 Upon information and belief, on or about October 10, 2000, a description of my 
invention was forwarded to the law firm of Townsend Townsend & Crew at which a 
patent application was prepared. See, Attachment B, Letter Dated October 10, 2000 

6 I hereby declare that all statements made herein based upon knowledge are true, 
and that all statements made based on upon information and belief are believed to be true, 
and further, that these statements were made with the knowledge that willful false 
statements and the like so made are punishable by fine or imprisonment, or both, under 
Section 1001 of Title 18 of the United States Code, and that such willful false statements 
may jeopardize the validity of the application or any patent issued thereon. 
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General Instrument Corporation® 

Intellectual Property Department 
For Internal Use Only 

Invention Record Form 

Gi Docket No,:^>52)g 

Administrative Information 

1 ., Short Descriptive Title of the Invention: 

HC4 Encryption for RTF with CODEC Changes ami Collision Resolution 

2 . Identify all persons who contributed to this invention, including persons from other divisions and/or outside 
companies: 


Full Legal Name Alexander Medvinsky 

Home Address 8873 Hampe Court 

City, State, Zip San Diego, CA 92129 

Citizenship United States 


Division/Co. Location Advanced Technology Dept. 

Motorola BCSSan Diego 


Office Phone No. 858-404-2367 


Mgr.'s Name & Phone No. Eric Sprunk 858-404-2426 


Signature of Inventor 

Date 9-12-2000 


inventor 3 Inventor 4 

Full Legal Name 

Home Address 

City, State, Zip 

Citizenship 

Division/Co. Location 

Office Phone No. _ 

Mgr.'s Name & Phone No. 

Signature of Inventor 

Date 


3. DCheck box if there are additional inventors listed on separate sheets. Additional information concerning 
inventors, if any 


GI CONFIDENTIAL & PROPRIETARY 


Rev. 02/98 


Invention Record Form 


II. Background Information 

1 . Do you believe this invention was developed while working under or in the performance of experimental, 
developmental or research work called for by a government contract or with the understanding that a 
government contract would be awarded? IEI No □ Yes If yes, please explain: 

2. Has your invention been disclosed to anyone outside Genera! instrument in a speech, exhibit, 
presentation, product, product manual, report, lecture, trade show, technical article, publication or 
otherwise? □ No M Yes If yes, please explain: 

It was presented to PacketCable standards group for IP Telephony over Cable, 

3. Is this invention related to any previous Gl invention disclosures of which you are aware (made by you or 
someone else)? M No □ Yes If yes, please explain: 

4. Name of product(s) and/or project(s) for which this invention was developed: 
This is part of our contribution to the PacketCable security standard, 

5. Planned or actual use of invention: 

Will implement inside our MTAs (Multimedia Terminal Adapters), which are IP Telephony clients., 

6. What economic benefits do you think Gl can derive from this invention? 

RC4 encryption is low-cost, fast and easy to implement. This invention makes RC4 encryption applicable 
to RTP by fixing some of the problems associated with media streams over IP. 

7. When do you expect a product incorporating this invention to be sold, offered for sale or shown to 
someone outside of Gl? (If a product or prototype has already been sold, offered for sale or shown, 
please identify the earliest date this happened.) 

In 2 nd quarter, 2001 , 

8. Has a working model of the invention been built and tested {or appropriate software been written)? 
S3 No □ Yes Sf yes, who has witnessed a demonstration, and when? 

9. List below any patents, publications, articles, texts, products, etc. which describe technology similar to 
your invention including reference materia! which may be useful in understanding the background 
technology of your invention. (Use a separate sheet if necessary and attach a copy of each item. Please 
include copies of all bibliographical information.) (Use a separate sheet if necessary) 

The attached email from me on November 22, 1999 outlined the technique of re-deriving RTP encryption 
keys when the RTP timestamp wraps around. This particular disclosure is re-using the same technique to 
solve additional RC4 encryption problems that were not considered at that time. 

Note that the technique described in the email was originally a result of a joint discussion at PacketCable. 
This disclosure doesn't cover that particular email. Instead, it covers the application of that same 
technique to solve additional RC4 encryption problems for RTP streams. 


Signature of Submitter(s) Date 

^ M3M 

Reatfand understood by [Witness Signature(s)] Date 
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HI. Description of the Invention 

1 . Please provide a very brief (i.e., one short sentence) summary of your invention. 

Provide secure RC4 encryption for RTP that allows for CODEC changes and resolution of SSRC (RTP source 
identifier) collisions, 

2. Briefly describe the field of technology to which your invention relates. 
This invention applies to RC4 encryption of any RTP streams, 

3. Briefly describe the problems, issues or needs which ted to the invention, 

RC4 is a stream cipher, where a random stream of bytes (key stream) is continuously generated and XOR-ed 
with the cleartext data to generate ciphertext (encrypted stream). There is a rule that the same portion of the key 
stream must not be reused to encrypt (XOR with) multiple messages. If this rule is not followed, the RC4 
encryption could be more easily broken. 

Within PacketCable, RTP timestamps are used as a pointer (synchronization source) into the RC4 random stream 
of bytes. Therefore whenever a timestamp is re-initialized, a new key stream has to be initialized, in order to 
avoid the re-use of the same key stream bytes. 
Specifically, for audio streams we have: 

RC4 Key Stream Offset = FrameNumber * FrameSize 
The frame number is number of the audio frame generated since the start of the stream and can be derived 
directly from the RTP timestamp: 

FrameNumber = (RTP Timestamp - RTP Initial Timestamp) / Nu 
where Nu is the number of audio samples in an uncompressed frame of audio 

After a CODEC change, FrameSize changes and the same formula can no longer be used to determine the RC4 
key stream offset, PacketCable specification attempted to solve this problem by re-adjusting the FrameNumber 
right after the code change as follows: 

FrameNumber_new = roof ((FrameNumbcr_oid + l)*(FrameSize_old / FrameSize_new) 
After this adjustment, the frame number will continue incrementing by l 

It turned out that {FrameNumber_new - FrameNumber_old) depends on the value of FrameNumber„old and if the 
codec change is not recognized at the same time on both endpoints, they will adjust their FrameNumber by a 
different offset . Since RTP is sent over UDP and some of the packets might be lost in transit, there is no 
guarantee that FrameNumberjDld during this adjustment will be the same on both sides. 

Therefore the PacketCable solution does not appear to work for Codec changes, which led to this invention. 
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4.. How have others addressed these problems, issues or needs? 
Not that I know of. 

5. Describe those particular features or functions of your invention which you think may be novel or technical 
advancements over the technology you listed in section 11.9. 

In 11.9, 1 referenced an email that allows for generation of new, non-repeating RC4 key streams when an RTP 
timestamp wraps around. A similar technique is re-used in this invention but for the new purpose of handling 
codec changes and RTP Source ID collisions without compromising the security of RC4 encryption. 

6. Best Mode: Describe any and all preferences you personally have regarding how to best implement, build, 
produce or use your invention (e.g., preferred parts, materials, techniques, etc. which you feel are best in 
practicing your invention). Each submitter's opinion is important here, even if there is disagreement. Please list 
anything you think will make the invention better in any way. 

This invention does not contain multiple modes. 

7 Briefly describe any alternative uses, variations or modifications of your invention which you contemplate. 

This invention was initially specified for RTP packets containing audio frames that use RTP timestamps as the 
RC4 synchronization source. In general, this invention applies to: 

• RTP encryption with any stream cipher that does not allow repetition of the key stream 

• RTP packets containing any content, including audio, video and event packets 

• An appropriate stream cipher synchronization source that is not necessarily the RTP timestamp. For example, 
the synchronization source could be the RTP sequence number or some other value inside the RTP header 
extension. 

If CODEC changes or RTP Source ID collision resolution require the synchronization source to be re-started, this technique 
can be applied to re-derive a new set of keys, to avoid a re-use of the same key stream. 

8, Please provide any additional information you think should be known by the attorney reviewing this form 

In an attached email from David Lide of Telogy, he said that they agree with the solution for mid-stream codec 
changes and would have proposed the same thing 

9. Please provide a detailed description of your invention. Your description should ideally provide as many details of 
your invention as possible in order to achieve optimal patent protection. An ideal disclosure should describe the 
construction and operation of the invention including drawings (flow charts, schematics, block diagrams, 
mechanical drawings, photographs, etc.) and any relevant engineering laboratory notebook pages, reports, 
program listings, etc. If you have already prepared reports or other descriptive information, there is no need to 
rewrite it. Simply attach it and reference it in your invention disclosure data sheet (for example, "see attached 9 
page engineering progress report addressed to John Doe dated 1 Jan., 1 992 for description of amplifier circuit") 

The invention is described in the attached document, labeled "Problems with 101 RC4-based Encryption and 
Proposed Solutions", dated on 9/5/2000. In particular, the invention is described in sections 3.1 and 4.1. 

The solution in this document refers to a pseudo-random function F(S, label), This function F generates a new 
pseudo-random set of bytes for each unique pair of values (S, label). The output of F is used as an RC4 
encryption key Any such pseudo-random function can be used - for example by applying a SHA-1 hash to the 
concatenation of S and label. 
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Problems with 101 RC4-based RTF Encryption and 
Proposed Solutions 

By Sasha Medvinsky, Motorola 


1 Introduction 

This memo assumes that RC4 is the required encryption algorithm and will remain the requited encryption 
algorithm in the near future. Therefore, it proposes solutions specific to RC4 and docs not explore the 
possibilities of using a block cipher instead Alternatives to RC4 that would provide sufficient performance 
for RTP encryption will be explored separately and are outside of the scope of this memo. 


2 Support for RFC 2833 (AVT Tones) 

RFC 2833 requires support for events that span multiple RTP packets in those cases, multiple consecutive 
RTP packets are required by this RFC 10 contain the same RTP timestamp - the one corresponding to the 
start of the event 

The 10 1 PacketCable security specification assumes that each RTP packet contains a new timestamp, where 
a timestamp is always incremented by a multiple of the audio frame size (measured in terms of audio 
samples) The specification does not disallow RTP event packets, but it does require that the timestamp is 
incremented lor each event packet the same way as it is done for norma! audio codec packets This clearly 
conflicts with RFC 2833, which requires support for multiple event packets with the same timestamp 


2. 1 Historical Overview of Previously Discussed Solutions 

The reason that the timestamp has to be unique for each RTP packet lor the 10 i security specification, is 
that it is used as a pointer into the RC4 key stream (which is XORed with the media stream to produce 
encrypted packets) it is generally considered insecure lor a stream cipher to re-use the same key stream 
bytes to encrypt multiple packets: 

On the other hand, it is highly desirable to use the timestamp as a pointer into the RC4 key stream One 
alternative would be the RTP sequence number, which has the following problems: 

a) It is too small, only 2 bytes, and might wrap around in the middle of a call - as often as 
several times an hour depending on the codec The MT A would have to keep track of the 
number of times the sequence number wraps around and couid possibly miss one of those, 
wrap arounds and loose sync 

b) The RTP header is only optionally authenticated (with MMH MAC) due to bandwidth 
considerations If someone were to maliciously change the sequence number, it would 
constitute a denial ol service attack. For example, the sequence number changed to Oxl'ff! 
would result in the receiver generating a large number of key stream bytes, trying to catch up 
with that sequence number 

On the other hand, the security specification recommends that a sanity check is performed on 
the RTP timestamp - to make sure it is within an expected window, calculated based on the 
MTA's running clock 

One solution previously considered by the security team but apparently flawed was to use the combination 
of timestamp and sequence number into the key stream In other words, when multiple packets are sent 
with the same timestamp, the timestamp points to a block of key stream bytes used to encrypt the whole 


group of packets and the sequence number points to the correct place within that block for encrypting each 
individual packet 

The problem with this approach is thai the sequence number does not tell you where you are within a 
particular timestamp (when the same timestamp is used on multiple packets) For example, let us say that 
two consecutive RTP event packets are sent with the same timestamp, the 1 st one was lost and the 2^ one 
was received. How does the receiver know that the lost RTP packet had the same timestamp? ft can't 
possibly know, but it needs to know in order to Find the correct place in the RC4 key stream 


2.2 Proposed Solution for RFC 2833 Support 

I propose to use the RTP header extension (as specified by RFC 1 889) This extension would be used only 
For consecutive RTP packets that contain the same timestamp In those cases, the extension would 
contain the time interval from the begi»iiin« of the 1 st packet with that same timestamp. The time 
interval would be expressed in terms of the number of audio frames (based on the current codec). 

When a timestamp is used for the very first time, this extension will not be used When a 2nd RTP packet 
is generated with the same timestamp, it will contain this extension Since for PacketCable, audio packets 

contain 1 , 2 or 3 frames, the value of this extension for the 2 nd packet will be 1 , 2 or 3. The exact format of 
this extension is TBD. 

The I" RTP packet with a new timestamp does not contain this RTP extension in order to conserve 
bandwidth.. It is assumed that all audio packets will have a new timestamp, while event packets will 
normally be smaller than audio packets (and thus the overhead associated with the extension will be 
absorbed by the smaller event packet size) Some codecs however could produce very small audio packets 
and in those cases the use of event packets would still require allocation of additional bandwidth 

More specifically, the 101 security specification defines the variable N| ; , a byte offset into the RC4 key 
stream as follows: 

N k = N f * (N c + NJ 

Here, N f is the count of the audio frames generated so far, N c is the max number of event bytes that can be 
generated within a duration of one audio frame and N m is the MAC size (which could be 0) 

And, Nf is calculated as follows: 

N,-= ( timestamp - RTP Initial Timestamp) / N u 
Here, N u is the number of speech samples in one frame of uncompressed audio 

The proposal in this section does not change any of the above calculations Instead, it proposes that the 
timestamp used to calculate Nr is defined as follows: 

timestamp = RTP Timestamp + extension * N u 

Flere, RTP timestamp is the actual timestamp in the RTP header and 'extension' is the value of this new 
extension in the RTP header If this extension is not present in the header, a value of 0 is assumed 

This proposal assumes that at the same time as event packets are generated, no audio packets will be sent 
out This rule is not apparent from reading RFC 2833, however if audio and event packets are allowed to 
be sent out at the same time it creates bandwidth allocation problems. It appeared from the last 
PacketCable architecture call that no one was in favor of that approach 

3 Mid-Stream Codec Changes 

The 101 specification defines the procedure for adjusting the RC4 key stream during codec changes, which 
is apparently flawed The main issue during codec changes is that the audio frame size can change The 


RTF limcslamp is used to determine the number oi audio frames processed so far and is thus required to be 
a multiple oj the audio frame size (plus a random initial value). 

After a codec change, all of a sudden the RTP timestamp is no longer a multiple of a new frame size The 
101 specification provides a formula for adjusting the timestamp, so that it will continue to be a multiple of 
!hc new audio frame size 

It turns out that the adjustment value added to the timestamp depends on exactly which audio frame is 
being processed when the codec change is discovered However, there is no guarantee with NCS signaling 
that the two communicating endpoints will be notified (by their CMS) of the codec change at exactly the 
same lime Thus, there is a pretty good chance that after the codec change the two MTAs will loose 
synchronization on their RC4 key streams and all RTP packets will decrypt to garbage 

3. 1 Proposed Solution for Mid-Stream Codec Changes 

The 10 1 security specification (updated by ECNs) currently provides for re-derivation of RTP keys when a 
time stamp wraps around In that case, the key derivation function is: 

F(S. "End-End RTP Key Change <N>") 
whesc N is a counter that holds tire number of times that the time stamp had wrapped around (For the 
specification of function F() and parameter S, please see the 101 security specification ) 

I propose that we redefine the meaning of counter N We can say that N is incremented whenever a new 
set of RTP keys has to be re-derived for the same media stream session And a new set of RTP keys has to 
be re-derived when: 

a) RTP timesSamp wraps around 

a) timesiamp is re initialized (after a codec change) 

When the codec changes, rather than adjusting the RC4 key stream, simply generate a new set of keys by 
re-executing the above key derivation function and start a whole new RC4 key stream. Because now N is 
incremented with each codec change, a new pseudo-random set of keys will be re-derived after each codec 
change 

4 SSRC Collision Resolution 

RFC 1889 requires that each endpoinl generating RTP session identifiers (SSRC) allows for the scenario 
when two identical SSRCs collide at a mixer or a bridge. RFC 1 889 also requires that during such a 
collision, an RTCP BYE message is used to hang up one of the RTP sessions and that a new one is 
restarted with a new SSRC value 

It is unclear as to what happens to the RTP sequence number and timesiamp when the RTP session is 
restarted after a BYE message. It appears possible that at least in some implementations the sequence 
numbers and the timestamp sequence are both re-initialized. Again, for security reasons when RC4 is used 
it is not acceptable to re-use the same RC4 key stream and re-start with the same initial timestamp value 

4. 1 Proposed Solution for SSRC Collision Resolution 

The proposed solution to this problem is very similar' to the one proposed for the codec changes. Again, the 
counter N in the derivation function is incremented whenever a new set of RTP keys has to be re-derived 
for the same media stream session. And a new set of RTP keys has to be re-derived when: 

b) RTP timestamp wraps around 

c) codec changes 

d) timestamp is re-initialized (after a codec change or after an SSRC collision 
resolution) 

Note that if the timestamp is not re-initialized after an SSRC collision there is no problem that needs to be 
fixed - the same RC4 key stream can continue to be used 


5 MAC Size Changes 

The security team iast approved that to support MAG size changes for RTP traffic, the key derivation 
function would include the RTP ciphersuite (including the MAC used) and during the MAC change new 
keys will be te-derived, 

While this method appears to work, since we are already using a counter to re-derive keys for other reasons 
(see above) To simplify the security specification we could also increment that same counter during die 
MAC size change 
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